home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16073 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 07:46:02 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829049335@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <4kcer3$mi4@solutions.solon.com>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Peter Seebach said
  13.  
  14. "Further, that behavior is a flat out bug; it is never correct, and the
  15. portability problem lies in the program, not the language spec.  The
  16. program needs to be fixed."
  17.  
  18. Gosh, I was a little concerned that when I wrote my "portable programs
  19. are portable" note that it would be considered too obvious, but Peter
  20. certainly is confused, so perhaps it is worth restating.
  21.  
  22. It is true of any language that a portable program is portable given:
  23.  
  24.   a portable program is one using only features of the language whose
  25.   semantics is target independent.
  26.  
  27.   the implementations of the language on the machines involved are
  28.   correct.
  29.  
  30. But this is quite useless in the discussion of portability problems. It
  31. is indeed clear that Peter has not been involved in large porting 
  32. efforts. His comments are reminiscent of an attitude that says "bugs
  33. in programs are not a problem - don't put bugs in your programs".
  34.  
  35. In practice portability problems (i.e. problems in porting programs)
  36. stem from several possible sources:
  37.  
  38.   o  Non-portable constructs introduced deliberately
  39.   o  Non-portable constructs introduced accidentally
  40.   o  Use of third party libraries etc, outside the language
  41.   o  Incomplete or inaccurate implementations
  42.  
  43. In practice, porting large programs tends to run into problems of
  44. each variety.
  45.  
  46. The language design is not exactly directly responsible in any of these
  47. areas, but it is also not completely independent of them either.
  48.  
  49. Non-portable constructs introduced deliberately
  50.  
  51.   Some languages make it more necessary to do non-portabe programming
  52.   than others, e.g. in C we cannot define integer types that have
  53.   portable ranges, in Ada we can easily do so.
  54.  
  55.   Some languages allow extensions more freely. For example, most languages
  56.   do not prohibit extensions in the standard -- the standard for COBOL for
  57.   example (like most others) defines what the required feature set is and
  58.   has nothing to say about programs outside the valid set. In the case of
  59.   Ada, the standard requires rejection of any program NOT in the valid set.
  60.  
  61. Non-portble constructs introduced accidentally
  62.  
  63.   This is more subjective certainly, but here too language plays a part.
  64.   For example both C and Ada allow the type model to be broken, C easily
  65.   with a cast, Ada only with a big syntactic stink about unchecked
  66.   conversion.
  67.  
  68.   Another area where this occurs is when specs are vague, the discussion
  69.   about read is a good example (although of course not directly relevant
  70.   since read is not a language feature). An example in C is the exact
  71.   semantics of X++ in a multi-threaded environment (there are obviously
  72.   two possible semantics, normally the same, but not in a threaded
  73.   environment).
  74.  
  75. Use of third party libraries etc
  76.  
  77.   This can obviously be alleviated by including more such stuff in the
  78.   language. Many people took the attitude that the original C language
  79.   did not include I/O, but the ANSI standard clearly takes an opposite
  80.   point of view and has incorporated many standard library routines.
  81.   Similarly, Ada 95 differs from Ada 83 in the addition of a large
  82.   standard library.
  83.  
  84. Incomplete or inaccurate implementations
  85.  
  86.   Small, simple languages are likely to fair better here. FOr example,
  87.   other things being equal, one would expect a C implementation to more
  88.   easily and consistently be a full implementation of its spec than an
  89.   Ada 95 or C++ implementation. Of course th "other things being equal"
  90.   here is important. External factors such as the quality of validation
  91.   suites, and the precision of the relevant standard, may well have
  92.   a significant influence.
  93.  
  94. But the bottom line here Peter is that we all know that in all languages
  95. it is possible for a very careful defensive programmer who knows the
  96. standard well, and who avoids likely trouble spots, can write portable
  97. code, especially if no system-dependent mucking is involved. But this
  98. has little to do with the practical issue of the world of portablity
  99. problems.
  100.  
  101. I certainly agree that programmers who know the relevant standard are
  102. in better shape. It amazes me to find out how few C programmers have
  103. read the C standard (similar situations are true with Fortrn and
  104. COBOL). Ada interestingly is different, typical professional Ada
  105. programmers do have a copy of the Ada standard at hand, at least
  106. for reference purposes.
  107.  
  108.